Method and system for performing mobile device-to-machine payments

ABSTRACT

A device with one or more processors, memory, and two or more communication capabilities obtains, from a payment module, an authorization request via a first communication capability (e.g., Bluetooth). The device sends, to a server, the authorization request via a second communication capability distinct from the first communication capability (e.g., cellular or WiFi technology). In response to sending the authorization request, the device obtains, from the server, authorization information via the second communication capability. After obtaining the authorization information, the device detects a trigger condition to perform a transaction with a payment accepting unit associated with the payment module. In response to detecting the trigger condition, the device sends, to the payment module, at least a portion of the authorization information via the first communication capability.

PRIORITY CLAIM

The present application is a continuation of U.S. patent applicationSer. No. 14/335,762, filed Jul. 18, 2014, now U.S. Pat. No. 9,547,859,which is a continuation of U.S. patent application Ser. No. 14/214,644,filed Mar. 14, 2014, now U.S. Pat. No. 8,856,045, which claims priorityto U.S. Provisional Patent Application No. 61/917,936, filed Dec. 18,2013, and U.S. patent application Ser. No. 14/214,644 is acontinuation-in-part of U.S. Design patent application Ser. No.29/477,025, filed Dec. 18, 2013, now U.S. Pat. No. D755,183. The presentapplication is based on and claims priority from these applications, thedisclosures of which are hereby expressly incorporated herein byreference.

BACKGROUND OF THE INVENTION

Disclosed herein are mobile-device-to-machine payment systems and, morespecifically, mobile-device-to-machine payment systems over anon-persistent network connection and featuring hands-free and manualmodes.

Vending machines (or “automatic retailing” machines), in the broadestsense, have been around for thousands of years. The first simplemechanical coin operated vending machines were introduced in the 1880s.Modern vending machines stock many different types of productsincluding, but not limited to drinks (e.g. water, juice, coffee, andsoda) and edible food products/items (e.g. snacks, candy, fruit, andfrozen meals), as well as a wide variety of non-food items. In this fastpaced world, vending machines are ubiquitous.

Vending machines are one type of “payment accepting unit” (paymentaccepting units are also referred to herein generically as “machines”).A payment accepting unit (or machine) is equipment that requires paymentfor the dispensing of products and/or services. In addition to vendingmachines, payment accepting units can also be other machines thatrequire payment for the dispensing of a product and/or servicesincluding, but not limited to parking meters, toll booths, laundromatwashers and dryers, arcade games, kiosks, photo booths, toll booths,transit ticket dispensing machines, and other known or yet to bediscovered payment accepting units.

In using a payment accepting unit, a user will (1) approach the paymentaccepting unit, (2) determine from the face of the payment acceptingunit the product (or service) he desires, (3) insert payment (e.g.coins, bills, or payment cards), and (4) input his selection into thepayment accepting unit using a user interface (e.g. a series of buttons,a key pad, touch screen, or other input mechanism using, for example,the column and row at which a product is located). Based on the user'sinputted selection, technology within the payment accepting unitprovides the desired product (or service) to the user.

As the number of people with internet-connected mobile devicesproliferates, so does the variety of uses for such devices. Mobilepayment is a logical extension.

There is a large development effort around bringing mobile payment tothe retail sector in an effort to not only provide options to the user,but also increased convenience.

In recent years, many improvements to modern vending machines have beensuggested. Many of the innovations relate to means for communicatingwith the vending machine. Some of these communication innovations aredetailed in U.S. Pat. No. 6,584,309 to Whigham (the “Whighamreference”), U.S. Pat. No. 7,085,556 to Offer (the “Offer reference”),U.S. Pat. No. 7,127,236 to Khan et al. (the “Khan reference”), U.S. Pat.No. 7,721,958 to Belfer et al. (the “Belfer reference”), U.S. Pat. No.8,396,589 to Katzenstein Garibaldi et al. (the “Garibaldi reference”),U.S. Pat. No. 8,489,140 to Weiner et al. (the “Weiner reference”), andInternational Publication No. WO/2008/083025 to Carlson (the “Carlsonreference”).

The Whigham reference is directed to a system and method for purchasinga product from an automatic vending machine by means of a consumer'scellular telephone. The consumer requests a product available from thevending machine by dialing a specified telephone number that connectsthe consumer's cellular telephone to a server operated by a billingagency. The server recognizes the request for the product, creates atransaction record, and communicates a vend code to the consumer. Uponreceiving the vend code from the server, the consumer transmits the vendcode to the vending machine. The vend code may be an RF code, an audibletone code, or a manual code. Upon receipt of the vend code from theconsumer, the vending machine dispenses the requested product.

The Offer reference is directed to a vending machine that is designed tocommunicate with a cellular phone such that it dispenses a product whenit receives information indicating that the product has been selected.The Offer reference teaches permitting the cashless utilization of avending machines via a communications service, such as a cellulartelephone. A response to a signal from the cellular telephone from

the vending machine that indicates that a connection has beenestablished between the vending machine and the cellular phone may be avisual indication that is displayed on the cellular telephone. Thevending machine outputs the cost of the product and that cost is debitedfrom an account to pay for the product.

The Khan reference describes a point of sale MicroAdapter device thatenables payment transactions to be effected through a purchaser'spersonal trusted device (e.g. the user selecting the micropaymentapplication on his personal trusted device and confirming or cancellingthe purchase thereon) without relying upon tokens or prepayment cards.In one embodiment, the MicroAdapter includes a transceiver configured toreceive a purchase signal from the personal trusted device includingorder and payment information. In response, the MicroAdaptercommunicates via wireless telephony with a transaction authorizer toreceive authorization for effectuating the purchase transaction. TheMicroAdapter can effectuate micropayment transactions authorized by aBilling On Behalf of Others program administered through a wirelesscarrier/ISP or third party.

The Belfer reference is directed to a system wherein a vending machinehas an audio code collector and a code validator that is adapted toreceive audio tones from a mobile device. The audio tones includeauthentication codes and dispense codes to control dispensing of productfrom the vending machine. To start the transaction, the consumer dials aunique set of symbols and digits to route the call to a verificationserver. The symbols and digits may correspond to a unique vendingmachine identification number and product identification numbers.

The Garibaldi reference is directed to an electronic device for the saleof intangible products through vending machines that include interfacesto communicate with external peripherals through the MDB protocol, theRS232 standard, and the DEX protocol, an interface to communicate withusers, a communications system that enables it to act as part of anetwork and communicate with a central system, and a controller, thatarticulates the communication among the above-mentioned components, soas to enable a central system to perform diverse actions on a vendingmachine.

The Weiner reference is directed to a system and method for providingproduct or service with a cellular telephone. The problem identified inthe Weiner reference is that mobile communication devices are long-rangeelectronic devices designed to be used for long-range communications.Eschewing the use of near-field communication because it requiresspecial design or modification of the mobile station (e.g. the vendingmachine), the Weiner reference teaches a mobile communication deviceidentifier, consisting of: a shielding defining a coverage area, theshielding arranged to reduce radio signals originating externally of thecoverage area to be less than a pre-determined signal strength; anantenna associated within the defined coverage area; a transceivercoupled to the antenna, the transceiver communicating with a mobilestation inserted within the defined coverage area utilizing a signalstrength greater than the pre-determined signal strength; and a servicecontrol unit responsive to the transceiver, the service control unitresponsive to the communication to output a signal indicative of anauthorization to provide a product or service.

The Carlson reference is directed to a system and a method for using aportable consumer device such as a mobile phone for payments and thelike. One embodiment of the Carlson system is directed to a method thatincludes the steps of receiving a payment request message (that includesa request to pay for a product from a vending machine) from a portableconsumer device operated by a consumer, sending an authorizationresponse message back to the vending machine wherein the vending machinesubsequently prompts the consumer to enter a selection if theauthorization response message indicates that the consumer is authorizedto make a purchase, and receiving an acknowledgement message from thevending machine that the product was purchased. The step of “sending anauthorization response message back to the vending machine” is performedby a remote payment server and would require a persistent networkconnection.

BRIEF SUMMARY OF THE INVENTION

Disclosed herein are mobile-device-to-machine payment systems and, morespecifically, mobile-device-to-machine payment systems over anon-persistent network connection and featuring hands-free and manualmodes.

Described herein is a mobile-device-to-machine payment system forfacilitating a cashless transaction for purchase of at least one productor service by a user from a payment accepting unit that preferably hasinput mechanisms. The user has a mobile device that has both short-rangecommunication technology and long-range communication technology. Thepayment accepting unit is capable of dispensing at least one product orservice. The system includes an adapter module and a server. The adaptermodule is associated with the payment accepting unit and has short-rangecommunication technology for communicating with the short-rangecommunication technology of the mobile device. The server has long-rangecommunication technology for communicating with the long-rangecommunication technology of the mobile device. The adapter module is forsending an authorization request for funds to the mobile device usingshort-range communication technology. The mobile device then forwardsthe authorization request for funds to the server using long-rangecommunication technology. The server is for sending an authorizationgrant for funds to the mobile device using long-range communicationtechnology. The mobile device the forwards the authorization grant forfunds to the adapter module using short-range communication technology.The payment accepting unit dispenses the at least one product or servicein response to receiving user input to the payment accepting unit inputmechanism if the adapter module has received the authorization grant.

The adapter module may have security technology and the server may havesecurity technology. The authorization request may be secured by theadapter module security technology to create a secured authorizationrequest. The authorization grant may be secured by the server securitytechnology to create a secured authorization grant. The securedauthorization request and the secured authorization grant are preferablyundecipherable to the mobile device.

The adapter module and the server may share a unique private key. Theadapter module may have encryption/decryption technology and the servermay have encryption/decryption technology. The authorization request maybe encrypted by the adapter module encryption/decryption technologyusing the unique private key to create an encrypted authorizationrequest. The encrypted authorization request may be decrypted by theserver encryption/decryption technology using the unique private key.The authorization grant may be encrypted by the serverencryption/decryption technology using the unique private key to createan encrypted authorization grant. The encrypted authorization grant maybe decrypted by the adapter module encryption/decryption technologyusing the unique private key. The encrypted authorization request andthe encrypted authorization grant are preferably undecipherable to themobile device.

The adapter module is preferably surrounded by two zones, a payment zoneand an authorization zone, wherein the payment zone is within theauthorization zone. The adapter module sends the authorization requestwhen the mobile device is within the authorization zone. The mobiledevice forwards the authorization grant for funds to the adapter modulewhen the mobile device is within the payment zone. A third zone possiblezone is a communication zone, the authorization zone being within thecommunication zone. The mobile device preferably receives advertisingbroadcast signals from the adapter module within the communication zone.

The system may have a hands-free mode in which the payment acceptingunit dispenses the at least one product or service without the userinteracting with the mobile device. A display of the payment acceptingunit may be used for displaying funds available based on informationfrom the authorization grant. The input mechanisms of the paymentaccepting unit may be used for receiving user selection input when theuser interacts with the input mechanisms to select the at least oneproduct or service to be dispensed.

The adapter module may be an in-line dongle for in-line insertion withina multi-drop bus of the payment accepting unit. Further, the paymentaccepting unit may have a multi-drop bus to a payment receivingmechanism. The multi-drop bus may have a male adapter and a femaleadapter. The adapter module may have a male adapter and a femaleadapter. The adapter module is preferably insertable in serial with themulti-drop bus by connecting the male adapter of the adapter module tothe female adapter of the multi-drop bus and by connecting the femaleadapter of the adapter module to the male adapter of the multi-drop bus.

Also described herein is a method for using a mobile-device-to-machinepayment system for facilitating a cashless transaction for purchase ofat least one product or service by a user from a payment accepting unitmay have input mechanisms. The user may have a mobile device having bothshort-range communication technology and long-range communicationtechnology. The payment accepting unit is preferably capable ofdispensing at least one product or service. The method includes thesteps of: (a) sending an authorization request for funds to the mobiledevice using short-range communication technology of an adapter moduleassociated with the payment accepting unit; (b) receiving theauthorization request for funds from the short-range communicationtechnology of the adapter module at the short-range communicationtechnology of the mobile device; (c) forwarding the authorizationrequest for funds to a server using the long-range communicationtechnology of the mobile device; (d) receiving the authorization requestfor funds from the long-range communication technology of the mobiledevice at long-range communication technology of the server; (e) sendingan authorization grant for funds to the mobile device using thelong-range communication technology of the server; (f) receiving theauthorization grant for funds from long-range communication technologyof the server at the long-range communication technology of the mobiledevice; (g) forwarding the authorization grant for funds to the adaptermodule using the short-range communication technology of the mobiledevice; and (h) receiving the authorization grant for funds from theshort-range communication technology of the mobile device at short-rangecommunication technology of the adapter module. At least one product orservice may then be dispensed from the payment accepting unit inresponse to receiving user input to the payment accepting unit inputmechanism if the adapter module has received the authorization grant.

The method may include the steps of securing the authorization requestusing security technology associated with the adapter module to create asecured authorization request, securing the authorization grant usingsecurity technology associated with the server to create a securedauthorization grant, and the secured authorization request and thesecured authorization grant are preferably undecipherable to the mobiledevice.

The method may include the steps of (a) sharing a unique private keybetween the adapter module and the server, (b) encrypting using theunique private key the authorization request using encryption/decryptiontechnology associated with the adapter module to create an encryptedauthorization request, (c) decrypting using the unique private key theencrypted authorization request using encryption/decryption technologyassociated with the server, (d) encrypting using the unique private keythe authorization grant using the encryption/decryption technologyassociated with the server to create an encrypted authorization grant,(e) decrypting using the unique private key the encrypted authorizationgrant using encryption/decryption technology associated with the adaptermodule, and (e) the encrypted authorization request and the encryptedauthorization grant are preferably undecipherable to the mobile device.

The method may include the steps of (a) surrounding the adapter modulewith two zones, a payment zone and an authorization zone, wherein thepayment zone is within the authorization zone, (b) the adapter modulesending the authorization request when the mobile device is within theauthorization zone; and (c) the mobile device forwarding theauthorization grant for funds to the adapter module when the mobiledevice is within the payment zone. The adapter module may also include athird zone, a communication zone, wherein the authorization zone iswithin the communication zone. The mobile device receives advertisingbroadcast signals from the adapter module within the communication zone.

The method may have a hands-free mode in which the payment acceptingunit dispenses the at least one product or service without the userinteracting with the mobile device. The method may further include thesteps of (a) displaying funds available on a display of the paymentaccepting unit, the funds available may be based on information from theauthorization grant; and (b) receiving user selection input when theuser interacts with input mechanisms of the payment accepting unit toselect the at least one product or service to be dispensed.

The method may include the step of inserting the adapter module as anin-line dongle for in-line insertion within a multi-drop bus of thepayment accepting unit. The method may include the step of inserting theadapter module in serial with the multi-drop bus by connecting a maleadapter of the adapter module to a female adapter of the multi-drop busand by connecting a female adapter of the adapter module to a maleadapter of the multi-drop bus.

The subject matter described herein is particularly pointed out anddistinctly claimed in the concluding portion of this specification.Objectives, features, combinations, and advantages described and impliedherein will be more readily understood upon consideration of thefollowing detailed description of the invention, taken in conjunctionwith the accompanying drawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a schematic diagram that shows three zones: a first“communication zone” (e.g. “Bluetooth range”), a second “authorizationzone,” and a third “payment zone.” The payment zone (that can't be zero)is smaller than or equal to (overlapping completely) the authorizationzone.

FIG. 2 is a schematic diagram that shows the three zone of FIG. 1 withmultiple users therein, the mobile-device-to-machine payment systemsproviding for managing and resolving multiple users.

FIG. 3 is a table that illustrates the hands-free credit or alert userprinciple.

FIG. 4 is a flow chart showing the logging RSSI at User Input.

FIG. 5 is a block schematic that shows elements of the system including,but not limited to, the adapter module, the machine, the mobile device,and exemplary servers, as well as communications therebetween.

FIG. 6 is a block schematic that shows there are three areas ofencryption used (each is bi-directional) between the adapter module, themachine, the mobile device, and/or exemplary servers.

FIG. 7 is a block diagram that communications, messaging, vendingsequence, and purchase flow between the adapter module, the mobiledevice, and a system management server.

FIG. 8A is a timing schematic diagram that shows additional elements andfeatures of the system including, but not limited to, communicationsmedium, messaging, vending sequence, and purchase flow, when the userenters the communication zone (Bluetooth Range).

FIG. 8B is a timing schematic diagram that shows additional elements andfeatures of the system including, but not limited to, communicationsmedium, messaging, vending sequence, and purchase flow, when the userenters the Authorization Zone.

FIG. 8C is a timing schematic diagram that shows additional elements andfeatures of the system including, but not limited to, communicationsmedium, messaging, vending sequence, and purchase flow, when the userenters the Payment Zone and, in particular, detailing the hands-freemode alternative and the swipe mode alternative.

FIG. 8D is a timing schematic diagram that shows additional elements andfeatures of the system including, but not limited to, communicationsmedium, messaging, vending sequence, and purchase flow, in a vendingtransaction including a loop for multiple transactions.

FIG. 8E is a timing schematic diagram that shows additional elements andfeatures of the system including, but not limited to, communicationsmedium, messaging, vending sequence, and purchase flow, in the Loginmode.

FIG. 8F is a timing schematic diagram that shows additional elements andfeatures of the system including, but not limited to, communicationsmedium, messaging, vending sequence, and purchase flow, during Modulebootup.

FIG. 8G is a timing schematic diagram that shows additional elements andfeatures of the system including, but not limited to, communicationsmedium, messaging, vending sequence, and purchase flow, during AccountCheck/Update.

FIGS. 9A-9E are flow charts that show exemplary steps and features ofthe system including, but not limited to, communications, messaging,vending sequence, and purchase flow.

FIGS. 10A-10D show an exemplary mobile device with a graphicalrepresentation of an exemplary mobile application shown thereon, themobile application being used as part of the mobile-device-to-machinepayment systems.

FIG. 11 is a perspective view of the exemplary first preferred in-linedongle adapter module.

FIG. 12 is a front plan view of the in-line dongle adapter module ofFIG. 11.

FIG. 13 is a back plan view of the in-line dongle adapter module of FIG.11.

FIG. 14 is a side view of the in-line dongle adapter module of FIG. 11in accordance with some implementations.

FIG. 15 is a first end view of a connector receptacle of the in-linedongle adapter module of FIG. 11.

FIG. 16 is a second end view of a connector receptacle of the in-linedongle adapter module of FIG. 11.

FIG. 17 is a perspective view taken from the first end of the in-linedongle adapter module of FIG. 11, the connectors and cables betweenwhich the in-line dongle adapter module is inserted being shown inbroken lines for environmental purposes.

FIG. 18 is a perspective view taken from the second end of the in-linedongle adapter module of FIG. 11, the connectors and cables betweenwhich the in-line dongle adapter module is inserted being shown inbroken lines for environmental purposes.

FIG. 19 is a perspective view of the in-line dongle adapter module ofFIG. 11 within a vending machine.

FIG. 20 is a perspective view of the exemplary second preferred in-linedongle adapter module.

FIG. 21 is a front plan view of the in-line dongle adapter module ofFIG. 20.

FIG. 22 is a back plan view of the in-line dongle adapter module of FIG.20.

FIG. 23 is a first side view of the in-line dongle adapter module ofFIG. 20, the second side being a mirror image of that shown.

FIG. 24 is a first end view of a connector receptacle of the in-linedongle adapter module of FIG. 20.

FIG. 25 is a second end view of a connector receptacle of the in-linedongle adapter module of FIG. 20.

FIG. 26 is a perspective view taken from the first end of the in-linedongle adapter module of FIG. 20, the connectors and cables betweenwhich the in-line dongle adapter module is inserted being shown inbroken lines for environmental purposes.

FIG. 27 is a perspective view taken from the second end of the in-linedongle adapter module of FIG. 20, the connectors and cables betweenwhich the in-line dongle adapter module is inserted being shown inbroken lines for environmental purposes.

FIG. 28 is a perspective view of the in-line dongle adapter module ofFIG. 20 within a vending machine.

FIG. 29 is a perspective view of the exemplary third preferred in-linedongle adapter module with a gap indicating the in-line dongle adaptermodule can be of any length.

FIG. 30 is a front plan view of the in-line dongle adapter module ofFIG. 29.

FIG. 31 is a back plan view of the in-line dongle adapter module of FIG.29.

FIG. 32 is a first side view of the in-line dongle adapter module ofFIG. 29, the second side being a mirror image of that shown.

FIG. 33 is a first end view of a connector receptacle of the in-linedongle adapter module of FIG. 29.

FIG. 34 is a second end view of a connector receptacle of the in-linedongle adapter module of FIG. 29.

FIG. 35 is a perspective view taken from the first end of the in-linedongle adapter module of FIG. 29, the connectors and cables betweenwhich the in-line dongle adapter module is inserted being shown inbroken lines for environmental purposes.

FIG. 36 is a perspective view taken from the second end of the in-linedongle adapter module of FIG. 29, the connectors and cables betweenwhich the in-line dongle adapter module is inserted being shown inbroken lines for environmental purposes.

FIG. 37 is a perspective view of the in-line dongle adapter module ofFIG. 29 within a vending machine.

FIG. 38 is a perspective view of the exemplary fourth preferred in-linedongle adapter module with two vertical gaps indicating the in-linedongle adapter module can be of any width.

FIG. 39 is a front plan view of the in-line dongle adapter module ofFIG. 38.

FIG. 40 is a back plan view of the in-line dongle adapter module of FIG.38.

FIG. 41 is a first side view of the in-line dongle adapter module ofFIG. 38, the second side being a mirror image of that shown.

FIG. 42 is a first end view of a connector receptacle of the in-linedongle adapter module of FIG. 38.

FIG. 43 is a second end view of a connector receptacle of the in-linedongle adapter module of FIG. 38.

FIG. 44 is a perspective view taken from the first end of the in-linedongle adapter module of FIG. 38, the connectors and cables betweenwhich the in-line dongle adapter module is inserted being shown inbroken lines for environmental purposes.

FIG. 45 is a perspective view taken from the second end of the in-linedongle adapter module of FIG. 38, the connectors and cables betweenwhich the in-line dongle adapter module is inserted being shown inbroken lines for environmental purposes.

FIG. 46 is a perspective view of the in-line dongle adapter module ofFIG. 38 within a vending machine.

FIG. 47 is a perspective view of the exemplary fifth preferred in-linedongle adapter module and, specifically, the longitudinal center portionthereof, the dashed line depiction of the sides indicating the sides ofthe in-line dongle adapter module can be of any shape or curvature.

FIG. 48 is a front plan view of the in-line dongle adapter module ofFIG. 47.

FIG. 49 is a back plan view of the in-line dongle adapter module of FIG.47.

FIG. 50 is a side view of the in-line dongle adapter module of FIG. 47in accordance with some implementations.

FIG. 51 is a first end view of a connector receptacle of the in-linedongle adapter module of FIG. 47.

FIG. 52 is a second end view of a connector receptacle of the in-linedongle adapter module of FIG. 47.

FIG. 53 is a perspective view taken from the first end of the in-linedongle adapter module of FIG. 47, the connectors and cables betweenwhich the in-line dongle adapter module is inserted being shown inbroken lines for environmental purposes.

FIG. 54 is a perspective view taken from the second end of the in-linedongle adapter module of FIG. 47, the connectors and cables betweenwhich the in-line dongle adapter module is inserted being shown inbroken lines for environmental purposes.

FIG. 55 is a perspective view of the in-line dongle adapter module ofFIG. 47 within a vending machine.

FIG. 56 is a block diagram of an exemplary adapter module.

FIG. 57 is a block diagram of an exemplary mobile device.

FIG. 58 is a block diagram of an exemplary server.

DETAILED DESCRIPTION OF THE INVENTION

Disclosed herein are mobile-device-to-machine payment systems and, morespecifically, mobile-device-to-machine payment systems over anon-persistent network connection. The mobile-device-to-machine paymentsystems disclosed herein focus on the unattended retail space (e.g. apayment accepting unit 120 or machine 120). More specifically,mobile-device-to-machine payment systems disclosed herein allow a user(having a mobile device 150 with a mobile application 140 thereon) tomake a cashless purchase from a payment accepting unit 120 (having anadapter module 100 associated therewith).

The mobile-device-to-machine payment systems described herein can beimplemented with one or more of the following features: easyinstallation feature, a non-persistent network connection feature; amanual (swipe to pay) mode feature; a hands-free mode feature; and amultiple vending transactions (multi-vend) feature.

Easy Installation: Installation is very easy, requires no tools,requires no configuration, and takes as little as 30 seconds. This isaccomplished by using an adapter module 100 such as an in-line dongle (ahardware device with software thereon) design for in-line insertionwithin a multi-drop bus (MDB) of a payment accepting unit (e.g. avending machine). Installation is as simple as “powering down” (turningoff) the machine 120, identifying the “wire” that connects with apayment receiving mechanism (e.g. the coin mechanism), disconnecting thewire (so that there are two loose ends, such as a male connection end oradapter of an MDB and a female connection end or adapter of an MDB),plugging (inserting) the adapter module 100 in serial (“in-line”) withthe wire (for example, connecting the MDB female adapter to a maleadapter of the adapter module 100 and connecting the MDB male adapter toa female adapter of the adapter module 100), tucking the wire and theinstalled adapter module 100 back into position, and “powering up”(turning on) the machine 120. Most vending machines made since 1995 havethis industry standard MDB technology that would allow this easy30-second installation. On machines without MDB technology, the adaptermodule 100 can be configured or designed to work with other serialprotocols or activate a switch. In essence the adapter module 100simulates establishing payment on payment accepting unit 120 in much thesame manner as other alternative forms of payment (e.g. cash).

Non-persistent Network Connection: Although payment accepting units (or“machines”) that accept only cash (e.g. paper currency and coins) maynot require a connection (persistent or non-persistent) to a network,traditional payment accepting units that accept cashless payments (e.g.credit cards, debit cards, and alternative mobile device payment methodsusing, for example, smart phones) require a persistent connection to anetwork (wired or wireless) to facilitate the cashless payments. Inother words, without a persistent (ongoing or accessible on demand)network connection, traditional payment accepting units cannot acceptcashless payments. Most traditional payment accepting units that acceptcashless payments include the technology to accomplish this persistentnetwork connection that allows them to connect to a remote server. Ifthe network connection to a traditional machine is temporarilyinterrupted, cashless payments will be temporarily unavailable. If themachine is located in a location where no signal is available, cashlesspayments will not be possible. The Whigham reference, the Offerreference, and the Belfer reference disclose alternative paymentaccepting units that accept cashless payments by using the user'scellular phone to allow the user to manually input coding to a remoteserver and, thereby act as an on-demand bridge network connection. Thesereferences, however, require significant user interaction with thecellular telephone to effectuate the transaction. In addition to using amobile device 150 as an intermediary between the payment accepting units120 and the server 130, mobile-device-to-machine payment systemsdescribed herein minimize (manual mode) or eliminate (hands-free mode)user interaction with the mobile device 150. Further, somemobile-device-to-machine payment systems described herein facilitate theacceptance of cashless payments without requiring any network connectionnear the payment accepting unit 120. Mobile-device-to-machine paymentsystems described herein that are located in a remote location where nosignal is available, therefore, can accept cashless payments.

Manual (Swipe to Pay) Mode: Using a “swipe to pay” feature (or just“swipe”) refers to a user's action implemented on his mobile device 150in which he quickly brushes his finger (or other pre-determinedinteraction) on the mobile device's touch screen 152 (or other inputdevice associated with the mobile device 150). From the user'sperspective, when the user is within range, a pre-installed mobileapplication 140 automatically connects to the payment accepting unit 120(e.g. a vending machine). The mobile application 140 might display (onthe touch screen 152) a prepaid balance that the user “swipes” totransfer payment to the payment accepting unit 120. The user couldobserve the transferred funds on the touch screen 152 of the mobiledevice 150 and/or on the display 122, 124 of the payment accepting unit120. The transaction is completed just as if cash was inserted in themachine 120 with the user inputting his selection on the paymentaccepting unit 120 and the payment accepting unit 120 dispensing theproduct or service. After the selection is made, the change is returnedto the mobile device 150 and this may be shown on the touch screen 152of the mobile device 150.

Hands-Free Mode: A “hands-free pay” feature (or just “hands-free”) wouldmost likely be used with “favorite” payment accepting units 120 (e.g. avending machine at work or school). From the user's perspective, hewould approach the favorite payment accepting unit 120 and notice thatthe display 122, 124 of the payment accepting unit 120 showed fundsavailable, he would select the product or service using the paymentaccepting unit's input mechanisms (e.g. buttons 126 or a touch screendisplay 124 shown in FIG. 19), and he would retrieve his dispensedservices or products. It would be that simple. More specifically, whenthe user is within range, a pre-installed mobile application 140automatically connects to the payment accepting unit 120 (e.g. a vendingmachine). The user may leave the mobile device 150 in a pocket, purse,briefcase, backpack, or other carrier. As the user approaches thepayment accepting unit 120 and is in approximately “arms-length”distance (e.g. 3 to 5 feet), the user could observe the transferredfunds on the display 122, 124 of the payment accepting unit 120. Thetransaction is completed just as if cash was inserted in the machine 120with the user inputting his selection on the payment accepting unit 120and the payment accepting unit 120 dispensing the product or service.After the selection is made, the change is returned to the mobile device150. FIG. 3 details when the hands-free mode would be available.

Multiple Vending Transactions (Multi-Vend): Both the “swipe to pay”feature and the “hands-free pay” feature could be used multiple times insequence (implemented, for example, as a loop) so that a user may makemultiple purchases. After making his first selection and receiving hisproduct (or service), the user would observe that additional funds wereavailable on the display 122, 124 on the payment accepting unit 120. Hecould make another selection (or multiple selections) and receiveadditional product(s) (or service(s)). More specifically, the display122, 124 may reset as if the transaction is complete, but then, becausethe user is still standing in range, the mobile application 140 wouldsend another credit to the payment accepting unit 120, allowing for asecond purchase. When the walks away, the system clears (e.g. returnsunused funds to the mobile application 140 on the mobile device 150.

The features described above, alone or in combination with otherfeatures described herein will revolutionize the hundred billion dollarautomated retail industry. The exemplary hardware is very low cost andthere are no reoccurring fees because no cellular connection is requiredon the machine 120. Using the mobile-device-to-machine payment systemsdescribed herein, operators can increase frequency of visits and itemssold with each visit.

Mobile-device-to-machine payment systems described herein may beimplemented as an apparatus and/or method for enabling payments to amachine 120 via a mobile device 150. Exemplary mobile-device-to-machinepayment systems may be better understood with reference to the drawings,but the shown mobile-device-to-machine payment systems are not intendedto be of a limiting nature.

Definitions

Before describing the mobile-device-to-machine payment systems and thefigures, some of the terminology should be clarified. Please note thatthe terms and phrases may have additional definitions and/or examplesthroughout the specification. Where otherwise not specifically defined,words, phrases, and acronyms are given their ordinary meaning in theart. The following paragraphs provide some of the definitions for termsand phrases used herein.

-   -   Adapter Module 100: As shown in FIGS. 1 and 2, the adapter        module 100 is a physical device that is installed in a machine        120 (a payment accepting unit 120). The shown exemplary adapter        module 100 is an in-line dongle (a hardware device with software        thereon) device that may be inserted in-line within a multi-drop        bus (MDB) of a machine 120. The adapter module 100 bridges the        communication between the machine 120 and a mobile device 150.        Although described as a unique component, it should be noted        that the adapter module 100 could be implemented as a plurality        of devices or integrated into other devices (e.g. components of        a machine 120). In its unique component form, the adapter module        100 can be easily inserted into a machine 120 so that the        machine 120 is able to perform new features with the assistance        of the adapter module 100. FIG. 56 shows exemplary components        associated with the adapter module 100. The shown example may be        divided into multiple distinct components that are associated        with each other or the example may be incorporated into or drawn        from other technology (e.g. a computer or a payment accepting        unit) as long as the components are associated with each other.    -   Mobile Device 150 and Application 140 (also referred to as a        “mobile application,” “mobile app,” or “app”): In general, a        mobile device 150 may be a user's personal mobile device 150.        The mobile device 150 (with a mobile application 140 thereon)        acts as a communication bridge between the adapter module 100        (associated with a payment accepting unit 120) and the server        130. The mobile device 150 and application 140, however, are not        “trusted” in that the communications (transmissions) it passes        are encrypted. Encrypted (secured) communications are        undecipherable (unencryptable, unreadable, and/or unuseable) by        the mobile device 150. This keeps the passed communications        secured and safe from hacking. Exemplary mobile devices include,        but are not limited to smart phones, tablet or laptop computers,        or personal digital assistants (PDAs), smart cards, or other        technology (e.g. a hardware-software combination) known or yet        to be discovered that has structure and/or capabilities similar        to the mobile devices described herein. The mobile device 150        preferably has an application 140 (app 140) running on it. The        term “app” is used broadly to include any software program(s)        capable of implementing the features described herein. FIGS.        10A-10D show exemplary mobile devices 150 with associated apps        140 associated therewith. It should be noted that the phrase        “mobile device” can be assumed to include the relevant app        unless specifically stated otherwise. Similarly, it should be        noted that an “app” can be assumed to be running on an        associated mobile device unless specifically stated otherwise.        FIG. 57 shows exemplary components associated with the mobile        device 150. The shown example may be divided into multiple        distinct components that are associated with each other or the        example may be incorporated into or drawn from other technology        (e.g. the cell phone itself) as long as the components are        associated with each other.    -   Payment Accepting Unit 120 (or Machine 120): A payment accepting        unit 120 (or machine 120) is equipment that requires payment for        the dispensing of an product and/or service. Payment accepting        units 120 may be vending machines, parking meters, toll booths,        laundromat washers and dryers, arcade games, kiosks, photo        booths, toll booths, transit ticket dispensing machines, and        other known or yet to be discovered payment accepting units 120.        Some payment accepting units 120 can accept cashless payments        (payments other than cash (paper currency and coins)) by        accepting payment from, for example, credit cards, debit cards,        and mobile devices.    -   Network Connections: For purposes of this discussion, a        persistent network connection is a wired or wireless        communications connection that is ongoing (e.g. a dedicated        connection, a dedicated online connection, and/or a hardwired        connection) or accessible on demand (e.g. the ability for the        machine to make a temporary connection to a server or the        ability for the user to contact a server from his mobile        device). Typically the persistent network connection has been        conducted over “long-range communication technology” (e.g.        hardwired, telephone network technology, cellular technology,        WiFi technology, wide area network (WAN), local area network        (LAN), or any wired or wireless communication technology over        the internet that is known or yet to be discovered).        Traditionally, machines that accept payment other than cash        require a persistent (ongoing or accessible on demand)        connection to a network to facilitate payment. This is true for        machines that accept, for example, credit cards and debit cards.        The payment accepting units 120 described herein do not require        a traditional persistent network connection. The user's mobile        device 150 acts as a communication bridge between the adapter        module 100 and the server 130. Communications between user        mobile devices 150 and the servers (e.g. a system management        server 130 and/or a funding source server 160) take place using        long-range communication technology. Communications between user        mobile devices 150 and the adapter module 100 of the payment        accepting unit 120 take place using “short-range communication        technology” (e.g. Bluetooth (e.g. Bluetooth 4.0, Bluetooth        Smart, Bluetooth LE (Low Energy), near-field communication,        Ultra Wideband (UWB), RFID, infrared wireless, induction        wireless, or any wired or wireless technology that could be used        to communicate a small distance (e.g. approximately a hundred        feet or closer) that is known or yet to be discovered). Neither        the adapter module 100 nor the payment accepting unit 120,        therefore require a traditional persistent long-range wireless        network connection. The exemplary communications technology        shown in the figures may be replaced with alternative like        communications technology and, therefore, specific shown        communications technologies are not meant to be limiting. For        example WiFi technology could be replaced with another        long-range communication technology.    -   Server: A server is the host processing server that may be        operated by the company running the system. For each user, the        server 130 preferably maintains at least one “virtual wallet”        having at least one “balance” (which can be $0) of designated        funds for which the server 130 keeps an accounting. The balance        may represent, for example, “cash” or it may be a “promotional        value” that represents funds that may be spent under certain        circumstances. If these funds begin to be depleted, the user may        be notified (e.g. via the application 140 on the mobile device        150) that additional funds need to be designated and/or        transferred. Alternatively, funds from other sources (e.g. the        funding source server 160) may be automatically transferred to        restore a predetermined balance. The balance may also be        increased based on a promotion (e.g. points earned or coupons).        As shown in FIG. 58, the server includes appropriate processors        950, memory 960 (which would keep an accounting of the user's        balance in a manner similar to a gift card), and communication        systems 970. As shown, the communications unit 970 of the server        130 includes long-range communication technology (e.g. cellular        technology and WiFi mechanisms). The server 130 also includes a        security unit 955 for encrypting and decrypting messages. The        server 130 receives an AuthRequest from the adapter module 100        (via a mobile device 150) and, if funds are available, returns        the AuthGrant for funds. FIG. 58 shows exemplary components        associated with the server 130. The shown example may be divided        into multiple distinct components that are associated with each        other or the example may be incorporated into or drawn from        other technology (e.g. a computer or a main frame) as long as        the components are associated with each other.    -   Advertise Presence: Each adapter module 100 advertises its        presence by broadcasting signals (advertising broadcast signals)        to mobile devices in the zones 102, 104, 016. Each adapter        module 100 can listen to other adapter modules' advertisements    -   Received Signal Strength Indicator (RSSI): The adapter module        100 may have a self-calibrating signal strength to determine        zone thresholds (e.g. a payment zone threshold). At the time the        user selects an item (product or service) from the payment        accepting unit 120, the Received Signal Strength Indicator        (RSSI) is logged. At this moment, it is presumed the user is        within “arms-length” (which may be a predetermined length        approximating the distance of a user standing in front of a        machine for the purpose of making a purchase) from the payment        accepting unit 120. Mathematical computation (In-Range        Heuristics) is conducted to derive the optimal RSSI threshold at        which point payment should be triggered by an application 140 on        a mobile device 150. The threshold may be payment accepting unit        specific and can vary over a period of time. This optimal zone        threshold is preferably reported to the mobile device 150 during        an initial handshake.    -   In-Range Heuristics: Mathematical computation that determines        the RSSI threshold to determine when a user is in the        authorization zone 104 and/or payment zone 102. This computation        can take into consideration numerous historical data points as        well as transaction specific information such as which mobile        device 150 is being used, payment accepting unit type, among        other factors. Preferably the RSSI is logged while the user is        making his selection (this is the one time in the entire process        that the user definitely will be “in range” (e.g. they will be        arm's length from the machine 120 because they are physically        interacting with the machine 120). The type of user mobile        device 150, accelerometer data (e.g. is the user moving or        stationary), and/or other information may also be logged while        the user is making his selection. The adapter module 100 can        give a reference RSSI for the payment zone 102 for the machine        120, and the application 140 can make a +/−adjustment based on        the specific mobile device 150 on which it is installed. Over a        period of time, the system continues to improve itself based on        additional data points.    -   Authorization Request (AuthRequest): When a user enters the        authorization zone 104, the mobile device 150 notifies the        adapter module 100 and the adapter module 100 sends the secured        authorization request (e.g. the encrypted authorization request)        as a “message” (also referred to as a communication or        transmissions) to the server 130 via the mobile device 150.        Encryption may be performed by a security unit 755 (security        technology that may be associated with the processing unit 750        and/or the memory 760). Significantly, the AuthRequest is a        request for authorization of funds, not a request for        authorization of a transaction. The purpose of the funds is        irrelevant to the server 30.    -   Authorization Grant Token (AuthGrant): This is a “message” (also        referred to as a communication or transmissions) encrypted by        the security unit 955 (security technology) of the server 130        with the unique private key for the adapter module 100. The        secured authorization grant (e.g. the encrypted authorization        grant) is passed from the server 130 (via the mobile device 150)        to the adapter module 100 in the form of a message. The mobile        device 150, however, is not able to decrypt and read the        message. The authorization grant is in response to the        authorization request. The amount of the funds granted by the        AuthGrant may be determined by factors including, but not        limited to, the amount of funds available (or, if funds are not        available, a mini-loan could be granted), a pre-authorized        amount (e.g. set by the server, set by the user during set-up,        set by the funding source, or a standard amount), limited by        time (e.g. only a certain amount per hour, or a predetermined        amount at specific times of the day), limited to the maximum        amount of an item on the machine (or enough for two or three        items in the machine), or one or more of these and other        factors. Significantly, the AuthGrant makes the funds available,        but does not authorize a transaction. The AuthGrant may have an        associated expiration period in that it may expire if it is not        used in a pre-determined time period. The length of time before        the AuthGrant expires may be determined by factors including,        but not limited to, the trustworthiness of the user (e.g. the        user has a long history with the system or some known provider        (e.g. credit card provider, bank, or credit union), the user has        a good credit rating, or the user has a large wallet balance), a        pre-authorized time period (e.g. set by the server, set by the        user during set-up, set by the funding source, or a standard        time period), limited by time (e.g. predetermined time periods        at specific times of the day such as longer times during        breakfast, lunch, and dinner), limited by the machine or the        products or services sold in the machine, limited by the number        of other users near the machine (e.g. if it is a crowded        machine, the AuthGrant may expire faster), or one or more of        these and other factors. The AuthGrant remains valid until it        expires or some other event occurs to end its validity (e.g. the        user cancels it). This means that under normal circumstances the        mobile device 150 will hold the AuthGrant authorizing use of        funds for a pre-determined time period that will allow the user        sufficient time to make a purchase. The authorized amount may be        considered to be the “wallet balance” that is held in a virtual        “wallet.”    -   Synchronization: Time may be synchronized to the adapter module        100 from the server 130. The server 130 sends time information        with encrypted messages and the adapter module 100 uses the time        encoded in the messages for synchronization.    -   The mobile-device-to-machine payment systems and components        thereof may have associated hardware, software, and/or firmware        (a variation, subset, or hybrid of hardware and/or software).        The term “hardware” includes at least one “processing unit,”        “processor,” “computer,” “programmable apparatus,” and/or other        known or yet to be discovered technology capable of executing        instructions or steps (shown as processing unit 750 in FIG. 56,        processing unit 850 in FIG. 57, and processing unit 950 in FIG.        58). The term “software” includes at least one “program,”        “subprogram,” “series of instructions,” or other known or yet to        be discovered hardware instructions or hardware-readable program        code. Software may be loaded onto hardware (or firmware) to        produce a “machine,” such that the software executes on the        hardware to create structures for implementing the functions        described herein. Further, the software may be loaded onto the        hardware (or firmware) so as to direct the        mobile-device-to-machine payment systems (and components        thereof) to function in a particular manner described herein or        to perform a series of operational steps as described herein.        “Hardware” such as the adapter module 100, mobile device 150,        and payment accepting unit 120 may have software (e.g. programs        and apps) loaded thereon. The phrase “loaded onto the hardware”        also includes being loaded into memory (shown as memory 760 in        FIG. 56, memory 860 in FIG. 57, and memory 960 in FIG. 58)        associated with or accessible by the hardware. The term “memory”        is defined to include any type of hardware (or other        technology)-readable media (also referred to as        computer-readable storage medium) including, but not limited to,        attached storage media (e.g. hard disk drives, network disk        drives, servers), internal storage media (e.g. RAM, ROM, EPROM,        FLASH-EPROM, or any other memory chip or cartridge), removable        storage media (e.g. CDs, DVDs, flash drives, memory cards,        floppy disks, flexible disks), firmware, and/or other known or        yet to be discovered storage media. Depending on its purpose,        the memory may be transitory and/or non-transitory. Appropriate        “messages,” “communications,” “signals,” and/or “transmissions”        (that includes various types of information and/or instructions        including, but not limited to, data, commands, bits, symbols,        voltages, currents, electromagnetic waves, magnetic fields or        particles, optical fields or particles, and/or any combination        thereof) over appropriate “communication paths,” “transmission        paths,” and other means for signal transmission including any        type of connection between two elements on the system (the        system including, for example, the adapter module 100, mobile        device 150, payment accepting unit 120, hardware systems and        subsystems, and memory) would be used as appropriate to        facilitate controls and communications.    -   It should be noted that the terms “programs” and “subprograms”        are defined as a series of instructions that may be implemented        as software (i.e. computer program instructions or        computer-readable program code) that may be loaded onto a        computer to produce a “machine,” such that the instructions that        execute on the computer create structures for implementing the        functions described herein or shown in the figures. Further,        these programs and subprograms may be loaded onto a computer so        that they can direct the computer to function in a particular        manner, such that the instructions produce an article of        manufacture including instruction structures that implement the        function specified in the flow chart block or blocks. The        programs and subprograms may also be loaded onto a computer to        cause a series of operational steps to be performed on or by the        computer to produce a computer implemented process such that the        instructions that execute on the computer provide steps for        implementing the functions specified in the flow chart block or        blocks. The phrase “loaded onto a computer” also includes being        loaded into the memory of the computer or a memory associated        with or accessible by the computer. Separate, albeit        interacting, programs and subprograms may be associated with the        adapter modules 100, the server 130, and the mobile device 150        (including the mobile application 140) and these programs and        subprograms may be divided into smaller subprograms to perform        specific functions.    -   The terms “messages,” “communications,” “signals,” and/or        “transmissions” include various types of information and/or        instructions including, but not limited to, data, commands,        bits, symbols, voltages, currents, electromagnetic waves,        magnetic fields or particles, optical fields or particles,        and/or any combination thereof. Appropriate technology may be        used to implement the “communications,” “signals,” and/or        “transmissions” including, for example, transmitters, receivers,        and transceivers. “Communications,” “signals,” and/or        “transmissions” described herein would use appropriate        technology for their intended purpose. For example, hard-wired        communications (e.g. wired serial communications) would use        technology appropriate for hard-wired communications,        short-range communications (e.g. Bluetooth) would use technology        appropriate for close communications, and long-range        communications (e.g. WiFi or Cellular) would use technology        appropriate for remote communications over a distance.        Appropriate security (e.g. SSL or TLS) for each type of        communication is included herein. Security units 755 and 955        include technology for securing messages. The security        technology may be, for example, encryption/decryption technology        (e.g. software or hardware). Although encryption/decryption is        discussed primarily as being performed using a unique private        key, alternative strategies include, but are not limited to        encryption/decryption performed using public/private keys, or        other encryption/decryption strategies known or yet to be        discovered. Appropriate input mechanisms and/or output        mechanisms, even if not specifically described, are considered        to be part of the technology described herein. The exemplary        communications unit 770 (shown in FIG. 56) of the adapter module        100 is shown as including appropriate input and output        mechanisms 772, 774 that may be implemented in association (e.g.        directly or indirectly in functional communication) with male        and female adapters 720, 730 of the adapter module 100. The        exemplary communications unit 870 (shown in FIG. 57) of the        mobile device 150 includes mechanisms for both long-range        communications (shown as Cellular and/or WiFi mechanisms 872)        for communicating with the server 130 and short-range        communications (shown as Bluetooth mechanisms 876) for        communicating with the adapter module 100.    -   When used in relation to “communications,” “signals,” and/or        “transmissions,” the terms “provide” and “providing” (and        variations thereof) are meant to include standard means of        provision including “transmit” and “transmitting,” but can also        be used for non-traditional provisions as long as the        “communications,” “signals,” and/or “transmissions” are        “received” (that can also mean obtained). The terms “transmit”        and “transmitting” (and variations thereof) are meant to include        standard means of transmission, but can also be used for        non-traditional transmissions as long as the “communications,”        “signals,” and/or “transmissions” are “sent.” The terms        “receive” and “receiving” (and variations thereof) are meant to        include standard means of reception, but can also be used for        non-traditional methods of obtaining as long as the        “communications,” “signals,” and/or “transmissions” are        “obtained.”    -   The term “associated” is defined to mean integral or original,        retrofitted, attached, connected (including functionally        connected), positioned near, and/or accessible by. For example,        if the user interface (e.g. a traditional display 122 (FIG. 19),        a touch screen display 124 (FIG. 19), a key pad 126 (FIG. 19),        buttons 126 (FIG. 19, shown as part of the key pad 126), a        keyboard (not shown), and/or other input or output mechanism) is        associated with a payment accepting unit 120, the user interface        may be original to the payment accepting unit 120, retrofitted        into the payment accepting unit 120, attached to the payment        accepting unit 120, and/or a nearby the payment accepting unit        120. Similarly, adapter modules 100 may be associated with        payment accepting units 120 in that the adapter modules 100 may        be original to the payment accepting unit 120, retrofitted into        the payment accepting unit 120, attached to the payment        accepting unit 120, and/or a nearby the payment accepting unit        120.    -   It should be noted that relative terms are meant to help in the        understanding of the technology and are not meant to limit the        scope of the invention. Similarly, unless specifically stated        otherwise, the terms used for labels (e.g. “first,” “second,”        and “third”) are meant solely for purposes of designation and        not for order or limitation. The term “short” in the phrase        “short-range” (in addition to having technology specific        meanings) is relative to the term “long” in the phrase        “long-range.”    -   The terms “may,” “might,” “can,” and “could” are used to        indicate alternatives and optional features and only should be        construed as a limitation if specifically included in the        claims.    -   It should be noted that, unless otherwise specified, the term        “or” is used in its nonexclusive form (e.g. “A or B” includes A,        B, A and B, or any combination thereof, but it would not have to        include all of these possibilities). It should be noted that,        unless otherwise specified, “and/or” is used similarly (e.g. “A        and/or B” includes A, B, A and B, or any combination thereof,        but it would not have to include all of these possibilities). It        should be noted that, unless otherwise specified, the terms        “includes” and “has” mean “comprises” (e.g. a device that        includes, has, or comprises A and B contains A and B, but        optionally may contain C or additional components other than A        and B). It should be noted that, unless otherwise specified, the        singular forms “a,” “an,” and “the” refer to one or more than        one, unless the context clearly dictates otherwise.

System Overview

FIGS. 5, 6, and 7 together show exemplary major components of themobile-device-to-machine payment system and the interactionstherebetwen.

As shown, the adapter module 100 functionally connected bi-directionallyto the payment accepting unit 120 via a wired serial connection suchthat no security is necessary. The adapter module 100 is alsofunctionally connected bi-directionally to the mobile device 150 (andits installed mobile application 140) via short-range communicationtechnology (e.g. a Bluetooth connection). Because the mobile device 150is not a “trusted” link (e.g. it could be hacked by a user), onlysecured communications (transmissions) are passed between the adaptermodule 100 and the mobile device 150. This keeps the passedcommunications secured and safe from hacking. The mobile device 150 (andits installed mobile application 140) is also functionally connectedbi-directionally to a system management server 130 and/or a fundingsource server 160 via long-range communication technology (e.g. WiFi orCellular connection) that preferably has appropriate security (e.g. SSLsecurity). Security between the mobile device 150 and the systemmanagement server 130 has the advantage of protecting communicationsfrom the mobile device 150 to the system management server 130 that mayinclude sensitive data and may not be encrypted. The system managementserver 130 and the funding source server 160 may be connected via awired Internet connection with SSL security. The system managementserver 130 may be connected via a wired Internet connection with SSLsecurity to an operators' server 170. Although not necessary toimplement a purchase transaction, for other purposes (e.g. inventory),the operators' server 170 may be connected to the payment accepting unit120 using a handheld computer sync or a cellular connection.

Also, a unique private key may be used to securely transmit encryptedmessages between the adapter module 100 and the system management server130 (although the encrypted transmissions would most likely be routedthrough the mobile device 150). The server 130 stores a private key foreach adapter module 100, and this key is only known to the adaptermodule 100 and the server 130. No intermediary is privy to this key(especially not the mobile device 150). When the adapter module 100 andserver 130 communicate messages (e.g. AuthRequest and AuthGrant), thesecurity unit 755 of the adapter module 100 encrypts the message withits private key and passes the message to the mobile device 150. Themobile device 150 (which preferably cannot decrypt the message) passesthe encrypted message to the server 130. The server 130 is able todecrypt the message using the security unit 955 of the adapter module100 and the unique private key. The security unit 955 of the server 130uses this same unique private key to encrypt messages to the adaptermodule 100 and sends the message to the mobile device 150 to relay tothe adapter module 100 that is able to decrypt the message using thesecurity unit 755 of the adapter module 100 and the unique private key.

FIG. 7 shows specific exemplary communications and messaging with anexemplary vending sequence (the numbers to the left of thecommunications and messaging) between the adapter module 100, the mobiledevice 150, and the system management server 130. These communicationsare discussed in more detail in the discussion pertaining to the timingschematics (FIGS. 8A-8G) and the flow charts (FIGS. 9A-9E).

It should be noted that FIGS. 5, 6, and 7 are meant to be exemplary andto help in the understanding of the mobile-device-to-machine paymentsystem. For example, the shown long-range communications technology maybe replaced with alternative long-range communications technology knownor yet to be discovered, the shown short-range communication technologymay be replaced with alternative short-range communication technologyknown or yet to be discovered, and the shown security may be replacedwith alternative security known or yet to be discovered. The shownconnections are meant to be exemplary in that, for example, there may beintermediaries that are not shown. The shown components have beensimplified in that, for example, only one mobile device 150 (or machine120, adapter module 100, or server 130) is shown where many may beincluded. Finally, the order of the steps may be changed and some stepsmay be eliminated.

Adapter Module

FIGS. 11-55 show exemplary adapter modules 100 a-100 e (referred togenerally as adapter modules 100). These are relatively low costhardware that are pre-configured to work with industry standard amulti-drop bus (MDB). On machines without MDB technology, the adaptermodule 100 can be configured or designed to work with other serialprotocols or activate a switch. In essence the adapter module 100simulates establishing payment on payment accepting unit 120 in much thesame manner as other alternative forms of payment (e.g. cash).

The shown exemplary adapter modules 100 are preferably designed to beused as an in-line dongle for in-line insertion within, for example, aMDB of a machine 120. The wire used in MDB technology uses male andfemale connection ends or adapters to allow the attachment ofperipherals. In the case of a vending machine, the wire with theconnection ends or adapters would be present to allow the attachment ofa payment receiving mechanism (e.g. a coin mechanism). The MDB male andfemale adapters 700, 710 may be separated (as shown in FIGS. 17, 18, 26,27, 35, 36, 44, 45, 53, and 54). The adapter modules 100 have male andfemale adapters 720, 730. The adapter module may be plugged (inserted)in serial (“in-line”) with the wire. For example, the MDB female adapter710 may be connected to the male adapter 720 of the adapter module 100and the MDB male adapter 700 may be connected to the female adapter 730of the adapter module 100. The resulting in-line configuration is shownin FIGS. 19, 28, 37, 46, and 55. It should be noted that the adaptermodules 100 are designed to allow pass-through communications so that ifthe mobile-device-to-machine payment systems is not enabled (e.g. for aparticular purchase or simply turned off) the MDB functions as thoughthe adapter module 100 is not there and the machine 120 can functionnormally.

Hands-Free

Summarily, if it is available, a hands-free mode, from the user'sperspective, would allow the user to approach a favorite paymentaccepting unit 120 and notice that the display (e.g. the displays 122 or124 shown in FIG. 19) associated with the payment accepting unit 120shows funds available (e.g. the wallet balance), he would select theproduct or service using input mechanisms (e.g. buttons 126 or a touchscreen display 124 shown in FIG. 19) associated with the paymentaccepting unit 120, and he would retrieve his dispensed services orproducts.

During an initial handshake with the mobile device 150 (when the user iswithin range), the adapter module 100 reports to the mobile device 150whether or not hands-free mode is available. If it is available, theinstalled mobile application 140 automatically connects to the paymentaccepting unit 120 without the user having to interact with the mobiledevice 150. The user observes that funds are available on the display122, 124 of the payment accepting unit 120 and completes the purchasetransaction as if cash was inserted in the machine 120 by inputting hisselection on the payment accepting unit 120. The payment accepting unit120 dispenses the product or service. After the selection is made, thechange is returned to the mobile device 150.

Whether hands-free payment is available is determined by factorsincluding, but not limited to whether if other mobile devices 150 are inrange, if other adapter modules 100 are in range, if there are anyalerts, if the payment trigger threshold is having wide variances and sodeemed unstable, or if the payment accepting unit operator (e.g. avending machine operator) has opted to disable hands-free mode for thepayment accepting unit 120. In the latter instance, operators candisable via a maintenance mobile device 150, as well as through theoperators' server 170 and/or the system management server 130.

FIG. 3 is a table that showing exemplary considerations, conditions, orfactors that may be used to determine whether the hands-free pay featureis available. Starting at the “Favorite?” column, this indicates whetherthe payment accepting unit 120 is a favorite machine. Preferably thehands-free pay feature is only available for use with “favorite” paymentaccepting units 120 (e.g. a vending machine at work or school). The“Alert” column has to do with whether there is some reason (e.g. thereare too many users in range) that the hands-free pay feature should notwork and, if there is such a reason, the user will be notified (alerted)and may be able to use the manual mode to resolve the alert and/orcomplete the transaction. FIG. 3 shows situations in which a user is oris not able to make hands-free purchases from a machine 120 using amobile application 140 on his mobile device 150. It should be noted thatthe shown interface is meant to be exemplary. For example, some of thefeatures could be automated or pre-selected. (It should be noted thatthe left hand column, the “Tab” column, relates to whether the selectedtab on the mobile application 140 is “all” or “favorite.” FIGS. 10A-10Dall show these tabs. Unlike the other columns in FIG. 3, this column hasmore to do with the functionality and view of the application 140 thanspecifically with the hands-free feature. The tabs would allow a user toselect whether he wanted to be alerted when he was in range of allpayment accepting units 120 or just “favorite” payment accepting units120 and the application 140 would show the appropriate view.)

Balance Display: An optional feature of the mobile-device-to-machinepayment system that is particularly helpful in the hands-free mode(although it may be available in the manual mode and/or in amultiple-vend scenarios) is when the user's mobile device 150 sends“credit” to the payment accepting unit 120 (either via hands-freepayment or through a manual swipe), the wallet balance is sent to thepayment accepting unit 120 that is then displayed to the user on adisplay 122, 124 of the machine 120. This is particularly beneficialduring hands-free mode when the user does not retrieve the mobile device150 and, therefore, may not know the balance. Also, in a multiple-vendscenario the user would not have to calculate a remaining balance.

An exemplary hands-free and multiple-vend scenario with a balancedisplay might be as follows: The user has $5.00 in his virtual wallet asthat is the amount that has been authorized (the AuthGrant being storedon the mobile device 150). He walks up to the payment accepting unit 120and $5.00 is displayed on the display 122, 124 of the payment acceptingunit 120 since hands-free mode was enabled and credit was sent (e.g. viashort-range communication technology) to the payment accepting unit 120.The user makes a selection of $1.50 by interacting (e.g. pressingbuttons) with the machine 120. The item (product or service) isdispensed and the “change” is “returned” (e.g. via short-rangecommunication technology) to the virtual wallet. But since user is stillstanding in the payment zone 102, the remaining wallet balance of $3.50is sent to the payment accepting unit 120 and displayed so that the usercan now see he has a $3.50 balance. (It should be noted that theauthorized funds may remain on the machine 120 and not be transferredback to the mobile device 150 between transactions.) The user decides topurchase a $1.50 item, and the transaction is completed as usual (e.g.by interacting with the machine 120). Now the user is still standing inthe payment zone 102 and he sees the wallet balance of $2.00 on thedisplay 122, 124 of the payment accepting unit 120. Deciding he does notwish to purchase anything else, the user walks away. As he walks out ofthe payment zone 102, the credit is cleared from the machine 120. But heis left with the knowledge that his wallet balance is $2.00 even thoughhe never touched the mobile device 150. Communications between thepayment accepting unit 120 and the adapter module 100 (via the mobiledevice 150) handle the accounting incidental to the transaction. Theremaining balance ($2.00) is technically stored on the server 130, andmay be reflected on the application 140 on the mobile device 150.

Multiple Distinct Zones

As shown in FIGS. 1 and 2, the functions performed by the adapter module100 can be divided into distinct zones: a first “communication zone”(e.g. “Bluetooth range” 106), a second “authorization zone” 104, and athird “payment zone” 102. The payment zone 102 (that can not be zero) issmaller than or equal to (overlapping completely) the authorization zone104. (Put another way, the payment zone 102 is within or coextensivewith the authorization zone 104.) The payment zone 102 is a subset ofthe authorization zone 104 with a ratio of the payment zone 102 to theauthorization zone 104 ranging from 0.01:1 to 1:1. It is not necessarilya fixed ratio and can vary between different payment accepting units120, different mobile devices 150, different users, and over time. Whilethe zones 102, 104, 106 are depicted as having a uniform shape, thezones may not necessarily be uniform (or constant over time) in that theshape can vary. For example, the shape of the Bluetooth range 106 mayvary depending on environmental conditions such as obstacles in the roomand payment accepting unit 120 door/wall materials.

Bluetooth Range 106: The outermost range is the Bluetooth range 106.This is the area in which the adapter module 100 is able to broadcastits presence. In most situations, the Bluetooth range 106 is a passiverange in that no actual data is exchanged between the mobile device 150and the adapter module 100. While in the Bluetooth range 106, the mobiledevice 150 monitors the RSSI (Received Signal Strength Indicator).

Authorization Zone 104: The middle region is the authorization zone 104.This is a computed area based on the RSSI. As mentioned, the mobiledevice 150 monitors the RSSI while it is in the Bluetooth range 106.When the RSSI reaches a certain predetermined threshold based onIn-Range Heuristics, the mobile device 150 can be considered to be inthe authorization zone 104. In the authorization zone 104 the mobiledevice 150 establishes a connection to the adapter module 100 (e.g. aBluetooth connection (FIG. 5) with SSL protection (FIG. 6)) and informsthe adapter module 100 of its presence. After a successful handshakewith the adapter module 100, the mobile device 150 registers the adaptermodule 100 and the adapter module 100 requests an authorization to theserver 130 via the mobile devices' network connection (e.g. a WiFi orcellular connection (FIG. 5) with SSL protection (FIG. 6)). It isimportant to note the mobile device 150 and the adapter module 100 havea non-exclusive relationship at this point. The adapter module 100 maycollect registrations for all mobile devices 150 that are within theauthorization zone 104.

An authorization occurs in preparation for when the user enters thepayment zone 102. An authorization expires in a set period of time (forexample, five minutes), so if the mobile device 150 is still in theauthorization zone 104 at the time of expiration, the adapter module 100submits for and receives another authorization. This will continue for aset number of times (for example, the limit may be three times to limitcases of numerous authorizations for a mobile device that may remain inthe authorization zone 104 for an extended period of time withoutcompleting a transaction). Should authorization fail (for instance ifthe limit had been reached) prior to the user entering the payment zone102, the adapter module 100 will request authorization when the mobiledevice 150 enters the payment zone 102 (which adds a few seconds to theexperience).

Payment Zone 102: As a user enters the payment zone 102, the mobiledevice 150 establishes exclusive control of the adapter module 100. Onceestablished, any other user in the payment zone 102 is put into a“waiting” status.

In the payment zone 102, the payment can be triggered automatically ifthe system has and is in hands-free mode. In such instances, the mobiledevice 150 is running the app 140 in background mode and will sendcredit to the payment accepting unit 120 without any explicit userinteraction. The user completes the transaction on the payment acceptingunit 120 in much the same manner as if cash had been inserted into thepayment accepting unit 120 to establish credit. After the user completesthe transaction (that may include one or more purchases), details of thetransaction are preferably returned to the mobile device 150 and server130 in separate messages. The message to the server 130 is preferablyencrypted with the adapter module's 100 private key (FIG. 6) to ensuredata integrity. As shown in FIG. 7, the “private key” coded message(Encrypted VendDetails) is preferably sent via the mobile device 150.The message to the mobile device 150 may be sent solely for the purposeof closing the transaction. The transaction history and balance areupdated server-side via the encrypted message sent to the server 130.

The other mode of operation is manual mode. In manual mode, the userlaunches the mobile device 150 and is able to swipe to send payment tothe payment accepting unit 120. The user can also swipe back to cancelthe payment. Like in hands-free mode, the purchase transaction iscompleted on the payment accepting unit 120 in the same manner as ifcash were inserted into the payment accepting unit 120. The mobiledevice 150 is only used to send payment. Selection is made directly onthe payment accepting unit 120.

Self-Calibrating Zone Threshold: A key, but optional feature, of thesystem is a self-calibrating payment zone RSSI threshold. Because RSSIcan vary machine to machine, environment to environment, and device todevice, having a fixed threshold at which payment is triggered can beproblematic. The approach suggested herein is the creation of aself-calibrating threshold. When the user is interacting with thepayment accepting unit 120 (such as when he makes his selection on thepayment accepting unit 120), the payment accepting unit 120 notifies theadapter module 100 and the adapter module 100 logs the conditions suchas RSSI, type of user mobile device 150, accelerometer data, and otherinformation. It is at this point that it can be ascertained safely thatthe user is within arms-length from the payment accepting unit 120 (bynecessity the user is arms-length because he is making some physicalinteraction with the payment accepting unit 120). This is the only pointin the entire transaction in which it can be certain that the user iswithin arms-length from the payment accepting unit 120.

FIG. 4 shows a simplified set of exemplary steps involved when usersenter the payment zone 102. Specifically, FIG. 4 shows that credit isestablished 200 (this may have been done in the authorization zone 104,but if not it would be handled in the payment zone 102), that the usermakes a selection using the machine 202, that the machine notifies theadapter module of the selection 204, that the adapter module(optionally) logs the RSSI 206, and that the purchase process(es)continues 208. Using the historically logged RSSI data, the adaptermodule 100 calculates one of several “average” RSSI using variousmathematical models. This “average” could be a traditional average, amoving average, a weighted average, a median, or other similar summaryfunction. The adapter module 100 could pre-process the historical databefore running the function, such as to eliminate top and bottom datapoints, suspect data points, etc.

Optionally, during the handshake between the mobile device 150 and theadapter module 100, the information transmitted to the adapter module100 may include, for example, the model of the mobile device 150. Usingthe received information pertaining to the mobile device models, theadapter module 100 can create multiple payment thresholds, one for eachmobile device model. This allows for variances that may be inherent indifferent types of Bluetooth radios. An alternative to this method isfor the adapter module 100 to broadcast a baseline payment zonethreshold, and the mobile device 150 can use an offset from thisbaseline based on its specific model type. The payment zone thresholds(or baseline offsets) can be unique to specific types of mobile devices(e.g. by manufacturer, operating system, or component parts), models ofmobile devices, or individual mobile devices (unique to each user).

In a typical scenario in which the payment zone threshold has beencalibrated, the adapter module 100 advertises its presence along withthe threshold at which it considers any mobile device 150 to be in theauthorization zone 104. This is a one-way communication from adaptermodule 100 to mobile device 150. Once the mobile device 150 enters theauthorization zone 104, there is a handshake that is established betweenthe adapter module 100 and the mobile device 150. During this handshake,the mobile device 150 can share its model information with the adaptermodule 100, and the adapter module 100 can return the payment zone 102threshold for that specific model.

Optionally, in addition to calibrating the payment zone threshold, theadapter module 100 can apply the self-calibrating model to theauthorization zone 104 to calibrate the authorization zone threshold. Aswith the payment zone thresholds, the authorization zone thresholds canbe unique to specific types of mobile devices, models of mobile devices,or individual mobile devices. In this scenario, the adapter module 100would broadcast multiple thresholds by device type and the mobile device150 would determine which threshold to apply (or alternatively broadcasta baseline and the mobile device 150 uses an offset based on its devicemodel). Even in this scenario, the authorization zone 104 is a one-waycommunication.

Optionally, along with the threshold that is calculated (in the paymentand/or the authorization zone(s)), a safety margin can be added tominimize scenarios in which a user is within range, but themobile-device-to-machine payment systems do not recognize it because thethreshold may not have been reached. For example, if the calculated RSSIfor an iPhone 5 on machine 4567 is −68 db, the mobile-device-to-machinepayment systems may add a safety margin of −5 db, and establish thethreshold at −73 db. So when a user's phone is communicating with theadapter module 100 at an RSSI of −73 db or better, themobile-device-to-machine payment systems will allow the mobile device150 to credit the payment accepting unit 120. The safety margin can beset on the server 130 and downloaded to the adapter module 100, or seton the mobile device 150, or set on the adapter module 100 itself.

Optionally, in the payment zone threshold, the mobile device 150 can useother data to determine when to cancel the exclusive control of thepayment accepting unit 120, to identify when the user is moving out ofthe payment zone 102. External data could include accelerometer datafrom the mobile device 150. Using that data, the mobile device 150 candetermine whether the user is standing relatively still in front of thepayment accepting unit 120, or if the user is in motion —effectivelywalking away from the payment accepting unit 120.

Signal Unavailability Adaptation

The mobile-device-to-machine payment systems described herein use amobile device's 150 short-range communication technology (shown asBluetooth mechanisms 876 in FIG. 57) and a mobile device's 150long-range communications technology (shown as Cellular and/or WiFimechanisms 872 in FIG. 57). The short-range communication technology 876communicates with the adapter module's 100 short-range communicationtechnology (shown as Bluetooth mechanisms 776 in FIG. 56). Thelong-range communications technology 872 communicates with the server's130 communication technology (not shown). The mobile device 150 (with amobile application 140 thereon) acts as a communication bridge betweenthe adapter module 100 (associated with a payment accepting unit 120)and the server 130. This process is described herein and works properlyif there is cellular or WiFi coverage within the payment zone 102.

One option if there is no cellular or WiFi coverage within the paymentzone 102 is to determine whether there is cellular or WiFi coveragewithin the authorization zone 104 or the Bluetooth range 106. If thereis, then the sizes of the zones 102, 104, 106 could be adapted and thetiming could be adapted. For example, if the mobile devices 150 detectedproblems with the cellular or WiFi coverage within the payment zone 102,the user could carry his mobile device 150 into the other zones (or themobile device 150 could use short-range communication technology tocommunicate with other mobile devices 150 within the authorization zone104 or the Bluetooth range 106) to determine whether the zones havecellular or WiFi coverage. If they do have coverage, communicationbetween the mobile device 150 and the server 130 can be advanced(conducted earlier when the mobile device 150 is further from themachine 120) or delayed (conducted later when the mobile device 150 isfurther from the machine 120). This can be thought of as changing thesize or shapes of the zones 102, 104, 106. The timing would also have tobe adjusted so that the authorization of funds (AuthGrant) does notexpire before the user has a chance to make a purchase. It also meansthat balance updates to the server 130 may happen after the user hasmoved away from the machine 120 and has cellular or WiFi coverage again.

Another option if there is no cellular or WiFi coverage within any ofthe zones 102, 104, 106 is for the user to obtain authorization whileoutside of the zones in a place with cellular or WiFi coverage. This mayoccur, for example, if a user knows that he will be going to a placewith a payment accepting unit 120 equipped with an adapter module 100(perhaps to a favorite payment accepting unit 120) that does not have(or rarely has) cellular or WiFi coverage. A user may also use themobile application 140 to query payment accepting units 120 in a givenrange (e.g. within 50 miles) or at a given location (e.g. at acampground or in a particular remote city) to determine whether there iscellular or WiFi coverage within the zones 102, 104, 106. The user canthen obtain pre-authorization from the server 130 using the mobileapplication 140. Again, the timing would also have to be adjusted sothat the authorization of funds (AuthGrant) does not expire before theuser has a chance to make a purchase. It also means that balance updatesto the server 130 may happen after the user has moved away from themachine 120 and has cellular or WiFi coverage again. Amobile-device-to-machine payment system having the ability to implementthis option would be able to accept cashless payments without requiringany network connection near the payment accepting unit 120.Mobile-device-to-machine payment systems described herein that arelocated in a remote location where no signal is available, therefore,can accept cashless payments.

As an example of a situation in which there might be no cellular or WiFicoverage within any of the zones 102, 104, 106 of a particular paymentaccepting unit 120, the user (a teenager) may be traveling to a remotelocation to attend summer camp where there is no cellular or WiFicoverage. The camp may have several payment accepting units 120 (e.g. amachine that creates a dedicated “hot spot” that requires payment foruse, vending machines, or machines for renting equipment (e.g. bikes,kayaks, or basket balls)). The camp facility might notify parents thatthe mobile-device-to-machine payment system is available. The parents,while at home, could obtain authorization for a particular amount (thatcould be doled out a certain amount per day or limited to type ofmachine or location) to be authorized and “loaded” into the user'smobile device 150 and specify that the authorization will not expire fora certain period or until a certain date. Thereafter, while at camp, theuser could use the mobile application 140 on his mobile device 150 in amanner similar to those discussed elsewhere herein. Short-rangecommunications may be used for communications between the adaptermodules 100 (associated with the machines 120) and users' mobile devices150.

One subtle but powerful component of the systems described herein isthat they require internet network connection only in the authorizationzone 104 and only for the time period required to send the AuthRequestand receive the AuthGrant. Once a valid AuthGrant is received by themobile device 150, an internet network connection is not required byeither the mobile device 150 or the adapter module 100 in the paymentzone 102 as long as the AuthGrant is valid (unexpired). This mechanismallows the system to seamlessly handle authenticated transactions in(temporary) offline mode, with the deferred acknowledgement andtransaction messages performing the bookkeeping and cleanup when networkconnection is regained. The alternatives described above provide aunique way to artificially extend the authorization zone to include anylocation where the mobile device 150 can communicate with the server130.

Multiple User Resolution

As shown in FIG. 2, in likely practical scenarios, there will bemultiple users in the zones 102, 104, 106. As shown, users 1, 2, and 3are in the payment zone 102 near the machine 120, users 5 and 6 areshown as positioned between the authorization zone 104 and the Bluetoothrange 106, users 4 and 7 are in the Bluetooth range 106, user 10 ispositioned on the edge of the Bluetooth range 106, and users 8 and 9 arepositioned outside of Bluetooth range 106. The mobile-device-to-machinepayment systems provide for managing, and resolving issues pertaining tomultiple users.

Users 4 and 7 are within the Bluetooth range 106 and user 10 is eitherentering or leaving the Bluetooth range 106. Within the Bluetooth range106 the users' mobile devices 150 are able to see the adapter module's100 advertisement. In this zone, the mobile device 150 preferably doesnot initiate a connection. The adapter module 100 is preferably unawareof the users in the Bluetooth range 106. All the adapter module 100 isdoing is advertising its presence to any multitude of users that may bein Bluetooth range 106.

The adapter module 100 begins to log users as the users (and theirrespective mobile devices 150) enter the authorization zone 104 (shownin FIG. 2 as users 5 and 6). At this point, there is a non-exclusiveconnection initiated by the mobile device 150 to the adapter module 100.It does a handshake (e.g. to exchange information needed to obtainauthorization and, optionally, to log information needed for aself-calibrating authorization zone threshold) and the mobile device 150contacts the server 130 for an authorization (e.g. sending anAuthRequest and receiving an AuthGrant). The adapter module 100registers all mobile devices 150 that have requested and receivedAuthGrants. The adapter module 100 continues communicating with anyother mobile device 150 that enters the authorization zone 104. Afterinitial contact, the adapter module 100 may provide the mobile device150 with a deferral delay of when to check back in with the adaptermodule 100 allowing opportunity for other mobile devices 150 tocommunicate with the adapter module 100.

If there is only one user in the payment zone 102, a purchasetransaction may be performed. If there are multiple users in the paymentzone 102, the mobile-device-to-machine payment system must handle thesituation.

One optional exemplary solution for handling the situation of themultiple users in the payment zone 102 is queuing users in the paymentzone 102. Once any mobile device 150 enters the payment zone 102, itestablishes exclusivity to a particular mobile device 150 (first comefirst serve). Technically, however, the adapter module 100 is notestablishing an exclusive connection to the mobile device 150. Theadapter module 100 can still perform a round-robin poll and communicatewith and advertise to other mobile devices 150. Instead, the adaptermodule 100 establishes a queue prioritized by RSSI and time (e.g. whowas first and whether the authorization has expired) and it notifies(e.g. alerts) other mobile devices 150 to wait. The earliest valid(unexpired) authorization takes precedence when there is any tie in theRSSI. Otherwise, for example, the strongest average RSSI takes priority.Preferably the queue is not a static measure of the RSSI but an averagedmeasure over the period of time in the queue. This compensates for ascenario in which a user may be walking around in the queue and thenshows up at the payment accepting unit 120 just as the previous user isfinishing. If another user was also in the payment zone 102 and stoodthere the entire time, but may have newer authorization, he could winout.

Anytime that the adapter module 100 cannot determine exactly which useris in the payment zone 102 in front of the payment accepting unit 120,the adapter module 100 will disable hands-free payment. The mobiledevice 150 will send an alert to the user and he can use swipe to pay(manual mode). All users in payment zone 102 will show “Connected” andthe first to swipe payment to the payment accepting unit 120 then locksout other users.

Multiple Module Resolution

In the scenario where there are multiple modules present, determiningwhich payment accepting unit 120 a user is in front of can be achallenge. The mobile-device-to-machine payment systems described hereinallow for adapter modules 100 to communicate to other adapter modules100 in range via Bluetooth. Each user receives authorization grants forspecific payment accepting units 120. This means if there are multipleadapter modules 100 within the same authorization zone 104, there willbe multiple authorization grants for the user. When the user enters thepayment zone 102, it can be difficult to differentiate which paymentaccepting unit 120 the user is in front of if the payment zones 102overlap.

To solve this problem, when the user enters the payment zone 102, theadapter modules 100 communicate with each other to determine the RSSIfor the particular user (based on the signal from his mobile device 150)to triangulate which adapter module 100 (and the associated paymentaccepting unit 120) is closer to the user. Optionally, the inter-modulecommunications can restrict the user to establishing an exclusiveconnection with only one payment accepting unit 120.

Optionally, when the user connects to a payment accepting unit 120, themobile device 150 can send a communication to the payment accepting unit120 for momentary display to the user on the display 122, 124 of thepayment accepting unit 120. For example, the mobile device 150 can senda communication (e.g. “connected” or “Fred's Mobile Device Connected”)to the payment accepting unit's display 122, 124 for a predeterminedperiod of time (e.g. 1-3 seconds) so when the user is in payment zone102, it is clear which payment accepting unit 120 the user is connectedto prior to making a purchase (either in hands-free or manual mode).

In addition, when the user is in manual mode, the mobile device 150 candisplay (e.g. on the touch screen 152 as shown in FIGS. 10A-10D) avisual indication of the payment accepting unit 120 (e.g. a pictureand/or a payment accepting unit ID of the payment accepting unit 120)for visual confirmation. If the user is in manual mode, the user canmanually change the payment accepting unit 120.

Descriptive Scenario

FIG. 7, FIGS. 8A-8G, and 9A-E (as well as other figures) can be used tounderstand a detailed exemplary scenario of the mobile-device-to-machinepayment systems described herein. An exemplary flow of communicationsand steps are loosely described below with reference to these (and otherfigures). It should be noted that alternative scenarios could include,for example, a modified order of the steps performed.

Prior to vending transactions, a user downloads a mobile app 140 ontohis mobile device 150, creates an account, and configures a fundingsource via, for example, a funding source server 160. A funding sourcemay be, for example, a debit card, a credit card, campus cards, rewardspoints, bank accounts, payment services (e.g. PayPal®) or other paymentoption or combination of payment options known or yet to be discovered.The funding sources may be traditional and/or nontraditional paymentsources that are integrated into the ecosystem described herein and thenused indirectly as a source of funds. Funds from the funding source arepreferably held on the server 130 such that when an AuthRequest isreceived by the server 130, the server 130 can send an AuthGrantauthorizing funds for a purchase.

The user can specify one or more “favorite” adapter module(s) 100 (thathas a one-to-one relationship to the payment accepting unit 120) that hemay visit regularly, such as a vending machine at school or work.Favorite adapter modules 100 appear on a pre-filtered list and allow foradditional rich features such as hands-free payment.

The payment accepting unit 120 may be equipped with an adapter module100 that is constantly advertising its availability via Bluetooth (orother “signals,” “communications,” and/or “transmissions”). This ongoingadvertising and scanning for adapter modules is shown in FIG. 8A. Asshown, the mobile device 150 is continuously scanning for any adaptermodule 100 within Bluetooth (or other “signal,” “communication,” and/or“transmission”) range. When the user is within range of that adaptermodule 100, the mobile device 150 tracks and monitors the signalstrength until a predetermined “authorization zone” threshold isachieved.

FIGS. 8B and 9A generally show that when the authorization zonethreshold is reached, the mobile device 150 enters the authorizationzone (block 302) and registers the adapter module 100. The mobile device150 connects to the server 130 (block 304). The app 140 on the mobiledevice 150 creates a request for authorization (AuthRequest) and passesthe AuthRequest to the server 130 using appropriate communicationtechnology (e.g. cellular or WiFi) (block 306). The server 130 respondswith an authorization grant (AuthGrant) encrypted with the specificadapter module's private key (block 306). This authorization token mayminimally include the User1 D, Apparatus1 D (for the adapter module100), authorization amount, and expiration time. The mobile device 150receives the AuthGrant from the server 130, and retains it until themobile device 150 is ready to issue payment to an adapter module 100.The mobile device 150 collects all pending AuthGrants that may be one ormore depending on how many adapter modules 100 are in-range. UnusedAuthGrants that expire are purged from the mobile device 150 and theserver 130. It is important to note that the mobile device 150 is unableto read the AuthGrant because it is encrypted with the adapter module'sunique private key that is only known to server 130 and adapter module100. This provides a preferred key element of security in the system asthe adapter module 100 only trusts AuthGrants that are issued by theserver, and the AuthGrants cannot be read or modified by the mobiledevice 150 or any other party in between the server and the adaptermodule 100. Additional mobile devices 150 may enter the authorizationzone 104 (block 308).

As the user approaches a specific adapter module 100, the user entersthe payment zone 102 and an event threshold is triggered based onheuristics performed by the mobile device 150. Blocks 310 and 312 showthe loop steps of waiting for a mobile device 150 from the authorizationzone 104 to enter the payment zone 102. If the user leaves theauthorization zone 104 without entering the payment zone 102, theadapter module 100 returns to advertising its presence (block 300).

FIGS. 8C and 9B generally show the user entering the payment zone. Themobile device 150 verifies that it has an unexpired and valid AuthGrant.If the AuthGrant is not good, it may be requested again, repeating theAuth Request process (block 315). If the AuthGrant is good, the mobiledevice 150 sends the valid AuthGrant (including the wallet balance(block 322)) to the adapter module 100 to initiate a transaction. Themobile device 150 may issue the AuthGrant automatically without specificuser interaction if the hands-free mode is supported (and the device isa favorite (block 318), there is only one device in the payment zone 102(block 318), and (optionally) there is only one user in theauthorization zone 104 (block 320). If any of these factors are notpresent, the mobile device 150 will prompt and/or wait for the user tobegin the transaction manually (block 324).

FIGS. 8D, 9C, and 9D generally show the transaction process. As shown inFIG. 9C, the adapter module 100 runs through a series of questions todetermine if there are any issues that would prevent vending including:has the user canceled in-app? (block 326), has the user walked away?(block 328), is the coin return pressed? (block 330), has more than apredetermined period of time elapsed? (block 332). If the answer to anyof these questions is “yes,” the transaction does not proceed. If theanswers to all of these questions is “no,” the user makes a selection(block 334) on the payment accepting unit 120 in the same or similarmanner as compared to if cash or credit were presented to the paymentaccepting unit 120. If the machine 120 is able to vend (block 336), itattempts to release the product. If the vend fails (block 338) it isreported by the machine (block 340) and a credit is returned to thevirtual wallet (block 342). If the vend is successful (block 338) it isreported by the machine (block 344). Put another way, after thetransaction is complete, the adapter module 100 returns to the mobiledevice 150 the details of the transaction as well as an encrypted packetcontaining the vend details to be sent to the server 130 via the mobiledevice 150. Optionally, the adapter module 100 can pass additionalinformation not directly related to the transaction such as paymentaccepting unit health, sales data, error codes, etc.

FIGS. 8D and 9E generally show the multi-vend function. If the machinehas enabled multi-vend capabilities (block 350) and the multi-vend limithas not been reached, the process returns to the question of whether theuser is in the payment zone (block 310 of FIG. 9A). If the machine doesnot have enabled multi-vend capabilities (block 350) or the multi-vendlimit has been reached, the wallet is decremented by the vend amount(s)and “change” is returned to the virtual wallet (block 354) and theprocess ends (block 356).

FIG. 8E is a timing schematic showing an exemplary Login process. FIG.8F is a timing schematic showing an exemplary bootup process. FIG. 8G isa timing schematic showing an exemplary Account Check/Update process.

Several of the figures are flow charts (e.g. FIGS. 9A-9E) illustratingmethods and systems. It will be understood that each block of these flowcharts, components of all or some of the blocks of these flow charts,and/or combinations of blocks in these flow charts, may be implementedby software (e.g. coding, software, computer program instructions,software programs, subprograms, or other series of computer-executableor processor-executable instructions), by hardware (e.g. processors,memory), by firmware, and/or a combination of these forms. As anexample, in the case of software, computer program instructions(computer-readable program code) may be loaded onto a computer toproduce a machine, such that the instructions that execute on thecomputer create structures for implementing the functions specified inthe flow chart block or blocks. These computer program instructions mayalso be stored in a memory that can direct a computer to function in aparticular manner, such that the instructions stored in the memoryproduce an article of manufacture including instruction structures thatimplement the function specified in the flow chart block or blocks. Thecomputer program instructions may also be loaded onto a computer tocause a series of operational steps to be performed on or by thecomputer to produce a computer implemented process such that theinstructions that execute on the computer provide steps for implementingthe functions specified in the flow chart block or blocks. Accordingly,blocks of the flow charts support combinations of steps, structures,and/or modules for performing the specified functions. It will also beunderstood that each block of the flow charts, and combinations ofblocks in the flow charts, may be divided and/or joined with otherblocks of the flow charts without affecting the scope of the invention.This may result, for example, in computer-readable program code beingstored in whole on a single memory, or various components ofcomputer-readable program code being stored on more than one memory.

Distinction from Known Systems

Many of the known systems and methods require that the payment acceptingunit be persistently (continuously) connected to and/or connectable ondemand to some sort of remote server in order to function. As anexample, the Carlson reference describes a system and a method for usinga portable consumer device. Described embodiments include a consumerusing the portable consumer device to dial a number to purchase an item(product or service) in a vending machine, to send an SMS to purchase anitem in a vending machine, or to use a mobile wallet to purchase an itemin a vending machine. It is mentioned in one embodiment that theconsumer may launch an application in the portable consumer device or,alternatively, the portable consumer device may automatically detect thevending machine and prompt the consumer to enter information associatedwith the vending machine. It should be noted, however, that even whenthere is automatic detection, the user is prompted to enter information(e.g. a machine alias, payment information, or a PIN) and it can beinferred that this is entered on the portable consumer device. Onceconnected to a payment processing network, the authorization processbegins using a payment processing network and/or payment server.Significantly, all of the embodiments described in the Carlson referencespecify that the payment server sends an authorization response messageto the vending machine. This means that, unlike themobile-device-to-machine payment systems described herein, a persistentnetwork connection is required for the Carlson system to function. Otherreferences that disclose systems that require a persistent networkconnection include the Khan reference (the MicroAdapter having thepersistent connection), the Garibaldi reference, and the Weinerreference.

Many of the known systems and methods require the user to significantlyinteract with their mobile devices. As an example, the Whigham referenceis directed to a system that eliminates the need for currency for avending machine and also eliminates the need for a dedicated onlineconnection between the vending machine and the issuer of a credit cardor a debit card. Instead the Whigham system and method allows a consumerto purchase a product from an automatic vending machine by using theconsumer's cellular telephone, personal digital assistant (P DA), orsimilar wireless communication device as a link between the provider ofthe products in the vending machine and the vending machine. The Whighamreference, however, sets forth a system and method requires significantinteraction between the consumer and his telephone including dialing atelephone number to a server (that, in turn, provides a vend code to theconsumer), requesting a specific product (e.g. by dialing additionaldigits, although this step is optional if a unique number was dialed fora specific product), and transmitting a vend code to the vendingmachine. (Other references that disclose systems that require userinteraction with the phone include the Offer reference, the Khanreference, the Belfer reference, and the Carlson reference.) In additionto other differences, some of the mobile-device-to-machine paymentsystems described herein do not require the user to interact with hismobile device at all, which can be contrasted to known systems andmethods that require the consumer to, for example, dial a telephonenumber, enter a machine identification, and/or enter a productidentifier using the mobile device to purchase a product.

The known systems and methods that use a cellular telephone tofacilitate cashless transactions at a vending machine use the cellulartelephone to authorize a particular transaction. For example, once theuser knows what he wants from a vending machine, he can dial a serverand receive authorization to make a specific purchase. Sometimes thisincludes dialing additional numbers on the cellular telephone to specifya particular product. The mobile-device-to-machine payment systemsdescribed herein take a completely different approach. Themobile-device-to-machine payment systems described herein are notspecifically interested in the details of the transaction to authorizethe transaction. Instead, the mobile-device-to-machine payment systemsfunction more like a gift card, a credit card, or a debit card in thatthey allow the user to have funds to make a purchase. When a user is inrange, the adapter module 100 (via a mobile device 150) sends anAuthRequest to the server 130 to preemptively obtain authorization tomake funds available. The server 130 returns the AuthGrant for funds tothe adapter module 100 (via a mobile device 150) so that the user mayuse the funds to make a purchase. The AuthGrant may remain valid untilit expires. This gives the user significantly more flexibility thanknown systems and methods.

Miscellaneous

It is to be understood that the inventions, examples, and embodimentsdescribed herein are not limited to particularly exemplified materials,methods, and/or structures. It is to be understood that the inventions,examples, and embodiments described herein are to be consideredpreferred inventions, examples, and embodiments whether specificallyidentified as such or not.

All references (including, but not limited to, foreign and/or domesticpublications, patents, and patent applications) cited herein, whethersupra or infra, are hereby incorporated by reference in their entirety.

The terms and expressions that have been employed in the foregoingspecification are used as terms of description and not of limitation,and are not intended to exclude equivalents of the features shown anddescribed. While the above is a complete description of selectedembodiments of the present invention, it is possible to practice theinvention using various alternatives, modifications, adaptations,variations, and/or combinations and their equivalents. It will beappreciated by those of ordinary skill in the art that any arrangementthat is calculated to achieve the same purpose may be substituted forthe specific embodiment shown. It is also to be understood that thefollowing claims are intended to cover all of the generic and specificfeatures of the invention herein described and all statements of thescope of the invention that, as a matter of language, might be said tofall therebetween.

1. (canceled)
 2. A method of payment processing, the method comprising:at a mobile device with one or more processors, memory, and acommunications unit: identifying a payment accepting unit based at leastin part on a transmission received from a payment module of the paymentaccepting unit; obtaining, from the payment module, an authorizationrequest via the communications unit of the mobile device; sending, to aserver, the authorization request via the communications unit of themobile device; in response to sending the authorization request,obtaining from the server authorization information via thecommunications unit of the mobile device, the authorization informationincluding information identifying an authorized amount for use inconjunction with the cashless transaction with the payment acceptingunit, the authorization information being associated with apredetermined time period within which the authorized amount is validfor use; after obtaining the authorization information, detecting atrigger condition to perform the cashless transaction with the paymentaccepting unit; in response to detecting the trigger condition,determining whether the authorized amount is available for use,including determining based at least in part on the predetermined timeperiod whether the authorized amount is available for use; and inaccordance with a determination that the authorized amount is availablefor use, sending to the payment module the information identifying theauthorized amount to enable completion of the cashless transaction atthe payment accepting unit.
 3. The method of claim 2, wherein: thetransmission at least includes authorization zone threshold criterion;and after receiving the transmission, initiating a handshake processwith the payment module, wherein the handshake process includes:sending, to the payment module, device information at least includinguser identification information corresponding to the user of the mobiledevice via the first transceiver; and receiving, from the paymentmodule, payment module information, wherein the payment moduleinformation at least includes an identifier corresponding to the paymentmodule.
 4. The method of claim 3, wherein sending the firstcommunication comprises: in accordance with a determination that theauthorization zone threshold criterion is satisfied, sending the firstcommunication to the payment module via the first transceiver, whereinthe first communication indicates that the authorization zone thresholdcriterion is satisfied; and wherein the device obtains the authorizationrequest in response to sending the first communication.
 5. The method ofclaim 3, wherein the payment module information further includes anindication that hands-free mode is available and payment zone thresholdcriterion.
 6. The method of claim 5, wherein the device informationfurther includes device identification information corresponding to amodel type of the mobile device; and wherein the payment zone thresholdcriterion is based at least in part on the device identificationinformation.
 7. The method of claim 5, wherein detecting the triggercondition comprises: determining whether the payment zone thresholdcriterion is satisfied; and in accordance with a determination that thepayment zone threshold criterion is satisfied, detecting the triggercondition without user input from a user at the mobile device.
 8. Themethod of claim 2, wherein detecting the trigger condition comprises:detecting a user input from a user of the mobile device; and in responseto detecting the user input, detecting the trigger condition to performthe cashless transaction with the payment accepting unit.
 9. The methodof claim 2, further comprising: in response to obtaining theauthorization information, presenting a notification to a user of themobile device that a connection has been established with the paymentmodule.
 10. The method of claim 9, wherein the notification furtherindicates the authorized amount for the transaction.
 11. The method ofclaim 2, wherein the authorization information includes an identifiercorresponding to the payment module, an identifier corresponding to theuser of the mobile device, an authorized amount, an authorization granttoken, and an expiration period for the authorization grant token. 12.The method of claim 11, wherein at least a portion of the authorizationrequest and the authorization grant token are encrypted with a uniqueencryption key corresponding to the payment module.
 13. A device,comprising: a first transceiver corresponding to a short-rangecommunication mode, and a second transceiver, distinct from the firsttransceiver, corresponding to a long-range communication mode distinctfrom the short-range communication mode; one or more processors; andmemory storing one or more programs to be executed by the one or moreprocessors, the one or more programs comprising instructions for:identifying a payment accepting unit based at least in part on atransmission received from a payment module of the payment acceptingunit; obtaining, from the payment module, an authorization request viathe communications unit of the mobile device; sending, to a server, theauthorization request via the communications unit of the mobile device;in response to sending the authorization request, obtaining from theserver authorization information via the communications unit of themobile device, the authorization information including informationidentifying an authorized amount for use in conjunction with thecashless transaction with the payment accepting unit, the authorizationinformation being associated with a predetermined time period withinwhich the authorized amount is valid for use; after obtaining theauthorization information, detecting a trigger condition to perform thecashless transaction with the payment accepting unit; in response todetecting the trigger condition, determining whether the authorizedamount is available for use, including determining based at least on thepredetermined time period whether the authorized amount is available foruse; and in accordance with a determination that the authorized amountis available for use, sending, to the payment module, the informationidentifying the authorized amount to enable completion of the cashlesstransaction at the payment accepting unit.
 14. The device of claim 13,wherein the transmission at least includes authorization zone thresholdcriterion; and after receiving the transmission, initiating a handshakeprocess with the payment module, wherein the handshake process includes:sending, to the payment module, device information at least includinguser identification information corresponding to the user of the mobiledevice via the first transceiver; and receiving, from the paymentmodule, payment module information, wherein the payment moduleinformation at least includes an identifier corresponding to the paymentmodule.
 15. The device of claim 14, wherein the sending the firstcommunication comprises: in accordance with a determination that theauthorization zone threshold criterion is satisfied, sending the firstcommunication to the payment module via the first transceiver, whereinthe first communication indicates that the authorization zone thresholdcriterion is satisfied; and wherein the mobile device obtains theauthorization request in response to sending the first communication.16. The device of claim 14, wherein the payment module informationfurther includes an indication that hands-free mode is available andpayment zone threshold criterion.
 17. The device of claim 16, whereinthe device information further includes device identificationinformation corresponding to a model type of the mobile device; andwherein the payment zone threshold criterion is based at least in parton the device identification information.
 18. The device of claim 16,wherein detecting the trigger condition comprises: determining whetherthe payment zone threshold criterion is satisfied; and in accordancewith a determination that the payment zone threshold criterion issatisfied, detecting the trigger condition without user input from auser at the mobile device.
 19. The device of claim 13, wherein detectingthe trigger condition comprises: detecting a user input from a user ofthe mobile device; and in response to detecting the user input,detecting the trigger condition to perform the cashless transaction withthe payment accepting unit.
 20. A non-transitory computer readablestorage medium storing one or more programs, the one or more programscomprising instructions, which, when executed by a device with one ormore processors and a first transceiver corresponding to a short-rangecommunication mode, and a second transceiver, distinct from the firsttransceiver, corresponding to a long-range communication mode distinctfrom the short-range communication mode, cause the device to performoperations comprising: identifying a payment accepting unit based atleast in part on a transmission received from a payment module of thepayment accepting unit; obtaining, from the payment module, anauthorization request via the communications unit of the mobile device;sending, to a server, the authorization request via the communicationsunit of the mobile device; in response to sending the authorizationrequest, obtaining from the server authorization information via thecommunications unit of the mobile device, the authorization informationincluding information identifying an authorized amount for use inconjunction with the cashless transaction with the payment acceptingunit, the authorization information being associated with apredetermined time period within which the authorized amount is validfor use; and after obtaining the authorization information, detecting atrigger condition to perform the cashless transaction with the paymentaccepting unit; and in response to detecting the trigger condition,determining whether the authorized amount is available for use,including determining based at least in part on the predetermined timeperiod whether the authorized amount is available for use; in accordancewith a determination that the authorized amount is available for use,sending, to the payment module, the information identifying theauthorized amount to enable completion of the cashless transaction atthe payment accepting unit.
 21. The non-transitory computer readablestorage medium of claim 20, wherein the transmission at least includesauthorization zone threshold criterion; and after receiving thetransmission, initiating a handshake process with the payment module,wherein the handshake process includes: sending, to the payment module,device information at least including user identification informationcorresponding to the user of the mobile device via the firsttransceiver; and receiving, from the payment module, payment moduleinformation, wherein the payment module information at least includes anidentifier corresponding to the payment module.
 22. The non-transitorycomputer readable storage medium of claim 21, wherein the sending thefirst communication comprises: in accordance with a determination thatthe authorization zone threshold criterion is satisfied, sending thefirst communication to the payment module via the first transceiver,wherein the first communication indicates that the authorization zonethreshold criterion is satisfied; and wherein the mobile device obtainsthe authorization request in response to sending the firstcommunication.
 23. The non-transitory computer readable storage mediumof claim 21, wherein the payment module information further includes anindication that hands-free mode is available and payment zone thresholdcriterion.
 24. The non-transitory computer readable storage medium ofclaim 23, wherein the device information further includes deviceidentification information corresponding to a model type of the mobiledevice; and wherein the payment zone threshold criterion is based atleast in part on the device identification information.
 25. Thenon-transitory computer readable storage medium of claim 23, whereindetecting the trigger condition comprises: determining whether thepayment zone threshold criterion is satisfied; and in accordance with adetermination that the payment zone threshold criterion is satisfied,detecting the trigger condition without user input from a user at themobile device.
 26. The non-transitory computer readable storage mediumof claim 20, wherein detecting the trigger condition comprises:detecting a user input from a user of the mobile device; and in responseto detecting the user input, detecting the trigger condition to performthe cashless transaction with the payment accepting unit.
 27. The methodof claim 2, wherein: the mobile device includes a touch-sensitivedisplay, and detecting the trigger condition includes detecting a swipegesture from a user at the touch-sensitive display of the mobile device.28. The method of claim 27, wherein: the swipe gesture is performed bythe user over a user interface object that is displayed on thetouch-sensitive display of the mobile device, and the user interfaceobject is specific to the payment accepting unit.